1. Field of the Invention
The present invention relates to Mobile IP network technology. More particularly, the present invention relates to Mobile IP authentication.
2. Description of the Related Art
Mobile IP is a protocol which allows laptop computers or other mobile computer units (referred to as “Mobile Nodes” herein) to roam between various sub-networks at various locations—while maintaining internet and/or WAN connectivity. Without Mobile IP or related protocol, a Mobile Node would be unable to stay connected while roaming through various sub-networks. This is because the IP address required for any node to communicate over the internet is location specific. Each IP address has a field that specifies the particular sub-network on which the node resides. If a user desires to take a computer which is normally attached to one node and roam with it so that it passes through different sub-networks, it cannot use its home base IP address. As a result, a business person traveling across the country cannot merely roam with his or her computer across geographically disparate network segments or wireless nodes while remaining connected over the internet. This is not an acceptable state-of-affairs in the age of portable computational devices.
To address this problem, the Mobile IP protocol has been developed and implemented. An implementation of Mobile IP is described in RFC 2002 of the Network Working Group, C. Perkins, Ed., October 1996. Mobile IP is also described in the text “Mobile IP Unplugged” by J. Solomon, Prentice Hall. Both of these references are incorporated herein by reference in their entireties and for all purposes.
The Mobile IP process and environment are illustrated in FIG. 1. As shown there, a Mobile IP environment 2 includes the internet (or a WAN) 4 over which a Mobile Node 6 can communicate remotely via mediation by a Home Agent 8 and a Foreign Agent 10. Typically, the Home Agent and Foreign Agent are routers or other network connection devices performing appropriate Mobile IP functions as implemented by software, hardware, and/or firmware. A particular Mobile Node (e.g., a laptop computer) plugged into its home network segment connects with the internet through its designated Home Agent. When the Mobile Node roams, it communicates via the internet through an available Foreign Agent. Presumably, there are many Foreign Agents available at geographically disparate locations to allow wide spread internet connection via the Mobile IP protocol. Note that it is also possible for the Mobile Node to register directly with its Home Agent.
As shown in FIG. 1, Mobile Node 6 normally resides on (or is “based at”) a network segment 12 which allows its network entities to communicate over the internet 4 through Home Agent 8 (an appropriately configured router denoted R2). Note that Home Agent 8 need not directly connect to the internet. For example, as shown in FIG. 1, it may be connected through another router (a router R1 in this case). Router R1 may, in turn, connect one or more other routers (e.g., a router R3) with the internet.
Now, suppose that Mobile Node 6 is removed from its home base network segment 12 and roams to a remote network segment 14. Network segment 14 may include various other nodes such as a PC 16. The nodes on network segment 14 communicate with the internet through a router which doubles as Foreign Agent 10. Mobile Node 6 may identify Foreign Agent 10 through various solicitations and advertisements which form part of the Mobile IP protocol. When Mobile Node 6 engages with network segment 14, Foreign Agent 10 relays a registration request to Home Agent 8 (as indicated by the dotted line “Registration”). The Home and Foreign Agents may then negotiate the conditions of the Mobile Node's attachment to Foreign Agent 10. For example, the attachment may be limited to a period of time, such as two hours. When the negotiation is successfully completed, Home Agent 8 updates an internal “mobility binding table” which specifies the care-of address (e.g., a collocated care-of address or the Foreign Agent's IP address) in association with the identity of Mobile Node 6. Further, the Foreign Agent 10 updates an internal “visitor table” which specifies the Mobile Node address, Home Agent address, etc. In effect, the Mobile Node's home base IP address (associated with segment 12) has been shifted to the Foreign Agent's IP address (associated with segment 14).
Now, suppose that Mobile Node 6 wishes to send a message to a corresponding node 18 from its new location. An output message from the Mobile Node is then packetized and forwarded through Foreign Agent 10 over the internet 4 and to corresponding node 18 (as indicated by the dotted line “packet from MN”) according to a standard internet protocol. If corresponding node 18 wishes to send a message to Mobile Node—whether in reply to a message from the Mobile Node or for any other reason—it addresses that message to the IP address of Mobile Node 6 on sub-network 12. The packets of that message are then forwarded over the internet 4 and to router R1 and ultimately to Home Agent 8 as indicated by the dotted line (“packet to MN(1)”). From its mobility binding table, Home Agent 8 recognizes that Mobile Node 6 is no longer attached to network segment 12. It then encapsulates the packets from corresponding node 18 (which are addressed to Mobile Node 6 on network segment 12) according to a Mobile IP protocol and forwards these encapsulated packets to a “care of” address for Mobile Node 6 as shown by the dotted line (“packet to MN(2)”). The care-of address may be, for example, the IP address of Foreign Agent 10. Foreign Agent 10 then strips the encapsulation and forwards the message to Mobile Node 6 on sub-network 14. The packet forwarding mechanism implemented by the Home and Foreign Agents is often referred to as “tunneling.”
During registration of a mobile node with its Home Agent, the identities of the sending party of the registration request (e.g., mobile node) and the sending party of the registration reply (e.g., Home Agent) are authenticated. During the registration process, a Mobile-Home Authentication Extension is typically appended to both the registration request and the registration reply. Upon receipt of the registration request by the Home Agent and the registration reply by the mobile node, the identity of the sending party is authenticated through the application of the Mobile-Home Authentication Extension.
RFC 2002 specifies the packet format for both the registration request and the registration reply packets that are sent between the mobile node and the Home Agent. As shown in FIG. 2, a registration request packet 202 and registration reply packet 204 both include a mandatory Mobile-Home Authentication Extension 206. More specifically, the mandatory Mobile-Home Authentication Extension 206 includes a type field 208, a length field 210, a security parameter index (SPI) field 212, and an authenticator 214. The type field 208 indicates the type of the extension (i.e., Mobile-Home Authentication Extension) and the length field 210 indicates the length of the extension (e.g., bytes). The Security Parameter Index 212 is an identifier which specifies a security association, or “row” in a security-association table, that a receiver should use to interpret a received packet. The security-association, described in further detail below, defines the key and the algorithm to be applied during the authentication process. Both the registration request packet 202 and the registration reply packet 204 include a protected area 216 which includes the registration request 202/registration reply 204, the type field 208, the length field 210, and the security parameter index (SPI) field 212. Both the mobile node and the Home Agent have access to the same secret key, provided by the security-association, which is used to hash this protected area 216 to create the authenticator 214.
FIG. 3 is a process flow diagram illustrating the process steps performed during authentication of a mobile node. As shown, the process begins at step 302 and at step 304, the mobile node constructs a registration request including a protected area. At step 306, the mobile node generates an authenticator by hashing the protected area with the key through application of a specified algorithm. The mobile node then sends the registration request which includes the protected area and the authenticator to the Home Agent at step 308. The Home Agent then identifies all necessary information such as the key and the algorithm used to generate its authenticator from a security-association, corresponding to the SPI of the registration request, at step 310. Next, at step 312, the Home Agent generates its authenticator by hashing the protected area of the registration request with the key using the algorithm identified by the SPI. The Home Agent then compares the authenticator generated by the mobile node with the authenticator generated by the Home Agent. If it is determined at step 314 that the authenticators match, the mobile node is authenticated at step 316 and the process is completed at step 318. However, if the authenticators do not match, the mobile node is not authenticated at step 320 and the process is completed at step 322. Authentication may similarly be performed by the mobile node upon receipt of the registration reply that is sent by the Home Agent. However, a different SPI and therefore security-association may be applied during authentication of the Home Agent.
As described with respect to the authentication process, a Security Association provides information that is used to generate the authenticators during the authentication process. FIG. 4 is a diagram illustrating a conventional security association table that is typically configured on each Home Agent. As shown, a security association table 402 typically includes at least one entry 404 for each mobile node supported by that Home Agent. By way of example, multiple security associations may be applicable to different types of data transfers which have different security requirements. Each entry 404 may include a mobile node identifier 406 for the mobile node such as the IP address of the mobile node and an SPI 408 identifying the security association within the security-association table. In addition, an authentication key 410 (e.g., a secret key) that is shared between the mobile node and the Home Agent is provided (e.g., keyed MD5). An algorithm 412 used to create the authenticator is provided (e.g., RSA Message Digest Algorithm MD5). Moreover, a mode 414 such as prefix, suffix, or prefix-suffix indicates the mode used during authentication. This indicates the portions of the protected region that are hashed with the key. In addition, each entry 404 further includes a replay timer 416, or timestamp, that indicates a maximum time during which the registration request may be replayed. The replay timer protects against unauthorized copying and “replaying” of registration requests for the purpose of defeating authentication.
Security-association tables may potentially include many thousands of entries and therefore consume a substantial amount of memory. As described above, at least one entry is typically provided in such security-association tables for each mobile node supported by the corresponding Home Agent. Moreover, these security-association tables are typically stored in non-volatile memory to prevent destruction of this information. This does not pose a problem when the Home Agent is a workstation having very large hard disks or other forms of non-volatile memory. However, when a network device such as a router or switch serves as the Home Agent, memory, particularly non-volatile memory, is a premium resource. Although the use of non-volatile memory ensures that security-associations will not be irretrievably lost, non-volatile RAM in a typical router is limited. By way of example, the non-volatile RAM may be approximately 128 kilobytes in a typical router. Since each security association consumes approximately 80 bytes of memory, the number of security associations that may be stored on a Home Agent is limited to about 1500. Actually, a portion of the router's NVRAM must be set aside for other purposes, so the actual number of security associations that it can store will be significantly less than the theoretical maximum. In short, the physical limitation in memory makes it impossible to store the security-associations for all mobile nodes that could otherwise be supported by a Home Agent.
In addition, the security-association tables are typically manually configured for each Home Agent. FIG. 5 is a block diagram illustrating a mobile IP network segment and associated environment. Mobile IP environment 502 includes the internet (or a WAN) 504 over which various mobile nodes can communicate remotely via mediation by a corresponding Home Agent (via an appropriately configured router denoted R1). An entity such as a corporation, business, or government may provide multiple Home Agents. Here, a first Home Agent 506, a second Home Agent 508, a third Home Agent 510, a fourth Home Agent 512, and a fifth Home Agent 514 are shown. As shown, such an environment lacks a centralized source of security associations. Therefore, each Home Agent must be separately configured for mobile nodes supported by that Home Agent. Moreover, redundant Home Agents may be provided to permit a Home Agent to serve as a backup to protect against failure by a primary Home Agent. By way of example, the fourth Home Agent 512 and the fifth Home Agent 514 may store identical security-associations in the event that one of the Home Agents fails. Thus, when a security-association is updated (e.g., a key is modified) the security-association must be updated on all of the redundant Home Agents. Accordingly, such a system requires considerable administrative overhead.
In view of the above, it would beneficial if a system having centralized database management were provided to store security-associations for mobile nodes supported by multiple Home Agents as well as perform Mobile IP authentication of these mobile nodes.